I love the sound of this, but I don't feel like I know exactly what use cases you are trying to enable or aiming to do. Can you give a bit more detail on what kind of things you aim to do? Is the (shiny future) goal to rewrite PartialEq and friends as some kind of fn that is written reflectively instead? Would it be generic over a data structure? Is the expectation that we could 'specialize" it to the type (and get efficiency)? Are you not sure yet, but you know the building block is X?

If you could give a high-level sketch of what these APIs might look like, that'd be great, and bonus points if you can sketch the whole set of connections you eventually imagine.

I don't want this goal to have everything designed up front or anything, I just want to understand the big pieces in your head.

I gave some more details, but

Are you not sure yet, but you know the building block is X?

is a very strong motivation here 😆 I have been wanting some sort of const eval that does type stuff for a long time, and consuming types is much easier than producing new types (which I want to do at some point), so why not start there

I second the question. :D I think what's missing is some hint of how you think things will go "out of" const-eval again. Like, I can see const-eval iterate over type information, we an expose almost arbitrary APIs to const-eval if we want to -- but then the typical use of reflection at comptime is to generate code, and const-eval can only generate values. Am I missing something obvious here or how is that supposed to work? Can we feed the result of a const-eval query into the parser and build new HIR from it? I assume that falls under the "insanely hard and requires major refactors" part, but is there a low-cost short-term version of this?

The low cost immediately possible version is creating new types and getting them back into the type system with a new type {} expression that const evaluates to a TypeId.

But I see that as out of scope for this goal. Just getting information out in the form of constants is sufficient for an MVP that would already replace most if not all need for bevy_reflect and facet (on nightly, with no RFC or plan for stabilization at this time, just trying to get en par with them to demonstrate feasibility)

Just getting information out in the form of constants is sufficient for an MVP that would already replace most if not all need for bevy_reflect and facet

Please go on, how can that be?
Is it that one can then use such const code to build up tables that those crates have their own logic for interpreting at runtime? Hm, I guess that's plausible. I see const-alloc coming up as a feature request very quickly here. ;)

Yea, they just process the things at runtime or preprocess things in const eval to end up with just table lookups at runtime.

Const alloc is useful but not necessary. Tho I am planning for it the moment we land const traits

I think there are interesting! I'm having a bit of trouble connecting them to the write-up above, perhaps because I don't quite get what alternatives you are weighing against.

This does not connect to the write-up above because it is a design axiom for how to write reflection, not why to do reflection. I link to more details below, but TLDR: I do not think uwuflection is the right way forward, as it is a very declarative/functional approach compared to the usual imperative const eval approach we use.

@tmandry would need to assign a champion here

ah, some of the details I wanted are here, though I had some trouble understanding some of these questions. e.g., "why not go full zig-style comptime" in particular felt like a bit of a nonsequitor.

maybe because I don't know zig that well

How will privacy be enforced? E.g. for serialization, it is important that private fields can be accessed in serde code. At the moment the privacy boundary is natural as the proc-macro generated code is inside the same module as the struct etc. Would it be possible to give serde access to some private fields, but not other random reflection code? Or is the idea that anything exposed to reflection should be the equivalent of a pub struct with pub fields, and any e.g. deserialisation validation would need to be pushed into a later conversion to a different type? Perhaps we'll need some #[reflect] macro to annotate some fields, though that would open a can of worms of which modifiers from serde and elsewhere to support.

I think we should just punt on this for now and see how far we can get with just public fields. If it turns out you want to be able to create values only via an API that does some sanity checks maybe we'll be able to figure something out, but we'll leave it out of an MVP (I give it a week of the first release of someone sticking data into doc comments on the type that guide their serializer to invoking methods instead of accessing fields 😆 )

Starting with just "everything must be pub" for the MVP sounds good to me, though it will be useful to keep track of since validation at deserialisation time is a killer feature of serde. Though ... if reflection can inspect (arbitrary) attributes on public fields, then maybe #[reflect(serde::serde(serialize_with = "path"))] could work where reflect would just provide the outer attribute but not parse anything inside (but e.g. serde could then act based on that)

This is a question for me too. Public-only makes sense as a starting point but I would like to see some ideas for how it can be extended to private fields too.

Also the ability to talk about whether a type is "complete" and has all fields available.

If we allow accessing private fields and types, then private fields and types are not a concept that exists anymore. Any change a crate author makes to private fields would become a breaking change now

I can see a system where we allow reflection to find From and Into impls or sth so you can get a public representation of a type with private fields. But I see no world where we'd stabilize private field accesses just like that.

The devil is in the details of course. We'll end to figure out whether const items in the same module can access private fields even if the access is in a comptime fn defined in another crate. Or whether a comptime fn defined in the same module of a private field can access that private field even if called in a const item outside of it.

I think this experiment is what will give us hands on experience with figuring out which cases are actually a semver issue.

This is just saying again that we can support serialization features that are non-goals of serde, right? How would it work?

I guess thinking about this specific case again, we can do that today by checking the type id of the serializer in the Serialize impl of a type, as long as that serializer is not generic itself (e.g. over the io::Write)

There's a point in between that I thought this proposal was going, where we give compile-time access to static properties of types without a derive. What use cases are enabled by inspecting values as opposed to types? Or are these different framings of the same thing?

Yea the core language feature is about types. The library part of this feature means that we'd want to be able to go from a &T to a reference to a field of that type

I'm persuaded this is a need since I've heard others ask for it, but why is it a part of this proposal?

EDIT: Maybe just add a forward-reference to the FAQ here.

I think this section should be combined with the above.

Is this better than adding a Reflect trait with this method (no comptime, no args) or an associated const?

ReflectFromVal could be added with a &self method; that could coerce to &dyn ReflectFromVal.

I guess this is more flexible because it accepts any TypeId, but it only supports calling at compile time which could be limiting, whereas the other approaches seem more forgiving.

I'm not sure what exactly you are proposing, but these operations are inherently comptime-only unless we generate a global reflection static for all types. That said, you can use this scheme to have a Reflect trait that is implemented for all types and has associated consts containing values.

Facet is relatively new, and seems to have an explicit goal to become a "new ecosystem standard". Do you think it would be worth letting that cook for a bit and waiting for some lessons learned to come out of it?

I am in contact with reflect people and they want a lot of these things that I'm proposing yesterday 😉

This is a question for me too. Public-only makes sense as a starting point but I would like to see some ideas for how it can be extended to private fields too.

Also the ability to talk about whether a type is "complete" and has all fields available.